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Monads have become a powerful tool for structuring effectful computations in functional program- 
ming, because they make the order of effects explicit. When translating pure code to a monadic 
version, we need to specify evaluation order explicitly. Two standard translations give call-by-value 
and call-by-name semantics. The resulting programs have different structure and types, which makes 
revisiting the choice difficult. 

In this paper, we translate pure code to monadic using an additional operation malias that ab- 
stracts out the evaluation strategy. The malias operation is based on computational comonads; we 
use a categorical framework to specify the laws that are required to hold about the operation. 

For any monad, we show implementations of malias that give call-by-value and call-by-name 
semantics. Although we do not give call-by-need semantics for all monads, we show how to turn 
certain monads into an extended monad with call-by-need semantics, which partly answers an open 
question. Moreover, using our unified translation, it is possible to change the evaluation strategy of 
functional code translated to the monadic form without changing its structure or types. 

1 Introduction 

Purely functional languages use lazy evaluation (also called call-by-need) to allow elegant programming 
with infinite data structures and to guarantee that a program will not evaluate a diverging term unless it 
is needed to obtain the final result. However, reasoning about lazy evaluation is difficult thus it is not 
suitable for programming with effects. 

An elegant way to embed effectful computations in lazy functional languages, introduced by Moggi 
|[T6l and Wadler f2E\, is to use monads. Monads embed effects in a purely functional setting and explic- 
itly specify the evaluation order of monadic (effectful) operations. 

Wadler |[26l gives two ways of translating pure programs to a corresponding monadic version. One 
approach leads to a call-by-value semantics, where effects of function arguments are performed before 
calling a function. However, if an argument has an effect and terminates the program, this may not be 
appropriate if the function can successfully complete without using the argument. The second approach 
gives a call-by-name semantics, where effects are performed only if the argument is actually used. How- 
ever, this approach is also not always suitable, because an effect may be performed repeatedly. Wadler 
leaves an open question whether there is a translation that would correspond to call-by-need semantics, 
where effects are performed only when the result is needed, but at most once. 

The main contribution of this paper is an alternative translation of functional code to a monadic form, 
parameterized by an operation malias. The translation has the following properties: 

• A single translation gives monadic code with either call-by-name or call-by-value semantics, de- 
pending on the definition of malias (Section When used in languages such as Haskell, it is 
possible to write code that is parameterized by the evaluation strategy (Section 14711 ). 
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• The translation can be used to construct monads that provide the call-by-need semantics (Sec- 
tion |4!2ll, which partly answers the open question posed by Wadler. Furthermore, for some mon- 
ads, it is possible to use parallel call-by-need semantics, where arguments are evaluated in parallel 
with the body of a function (Section l43] ). 

• The malias operation has solid foundations in category theory. It arises from augmenting a monad 
structure with a computational semi-comonad based on the same functor (Section [3]). We use this 
theory to define laws that should be obeyed by malias implementations (Section 1X21) . 

This paper was inspired by work on joinads (19], which introduced the malias operation for a similar 
purpose. However, operations with the same type and similar laws appear several times in the literature. 
We return to joinads in Section l4!4l and review other related work in Section|5l 

1.1 Translating to monadic code 

We first demonstrate the two standard options for translating purely functional code to monadic form. 
Consider the following two functions that use pureLookupInput to read some configuration property. 
Assuming the configuration is already loaded in memory, we can write the following pure computatioiiU: 

chooseSize ::Int — t- Int — ?• Int 
chooseSize new legacy = 

if new > then new else legacy 

result Size '.'.Int 
result Size = 

chooseSize {pureLookupInput "new_size") 

{pureLookupInput "legacy_size") 

The resultSize function reads two different configuration keys and chooses one of them using chooseSize. 
When using a language with lazy evaluation, the call pureLookupInput "legacy_size" is performed 
only when the value of "new_size" is less than or equal to zero. 

To modify the function to actually read configuration from a file as opposed to performing in-memory 
lookup, we now use lookuplnput which returns 10 Int instead of the pureLookupInput function. Then we 
need to modify the two above functions. There are two mechanical ways that give different semantics. 

Call-by-value. In the first style, we call lookuplnput and then apply monadic bind on the resulting 
computation. This reads both of the configuration values before calling the chooseSize function, and so 
arguments are fully evaluated before the body of a function as in the call-by-value evaluation strategy: 

chooseSize chv ''Int — )• Int — )• 10 Int 
chooseSize chv new legacy = 

return (if new > then new else legacy) 

resultSize chv '■ '■ 10 Int 
resultSizechv = do 

new ^ lookuplnput ^jy^, "new_size" 

legacy ^ lookuplnput ^j,^, "legacy_size" 

chooseSizecbv new legacy 

'Examples are written in Haskell and can be found at: |http : //www . cl . cam, ac ■uk/-tp322/papers/malias .html] 



70 



Evaluation strategies for monadic computations 



In this version of the translation, a function of type A — )• 6 is turned into a function A ^ M B. For 
example, the chooseSizectv function takes integers as parameters and returns a computation that returns 
an integer and may perform some effects. When calling a function in this setting, the arguments may not 
be fully evaluated (the functional part is still lazy), but the effects associated with obtaining the value of 
the argument happen before the function call. 

For example, if the call lookuplnput ^i,^, "new_size" read a file and then returned 1024, but the 
operation lookuplnput ^i,^ "legacy_size" caused the program to crash because a specified key was not 
present in a configuration file, then the entire program would crash. 

Call-by-name. In the second style, we pass unevaluated computations as arguments to functions. This 
means we call lookuplnput to create an effectful computation that will read the input, but the computation 
is then passed to chooseSize, which may not need to evaluate it: 

chooseSizechn '' lO Int —> 10 Int — >■ lO Int 
chooseSizecbn new legacy = do 
newVal ■<— new 

if newVal > then new else legacy 

resultSizecbn ■■ 10 Int 
resultSizecbn = 

chooseSizecbn {lookuplnput "iiew_size") 

{lookuplnput "legacy_size") 

The translation turns a function of type A ^ B into a function M A ^ M B. This means that the 
chooseSizecbn function takes a computation that performs the I/O effect and reads information from the 

configuration file, as opposed to taking a value whose effects were already performed. 

Following the mechanical translation, chooseSizecbn returns a monadic computation that evaluates the 
first argument and then behaves either as new or as legacy, depending on the obtained value. When the 
resulting computation is executed, the computation which reads the value of the "new_size" key may 
be executed repeatedly. First, inside the chooseSizecbn function and then repeatedly when the result of 
this function is evaluated. In this particular example, we can easily change the code to perform the effect 
just once, but this is not generally possible for computations obtained by the call-by-name translation. 

2 Abstracting evaluation strategy 

The translations demonstrated in the previous section have two major problems. Firstly, it is not easy to 
switch between the two - when we introduce effects using monads, we need to decide to use one or the 
other style and changing between them later on involves rewriting of the program and changing types. 
Secondly, even in the 10 monad, we cannot easily implement a call-by-need strategy that would perform 
effects only when a value is needed, but at most once. 

2.1 Translation using aliasing 

To solve these problems, we propose an alternative translation. We require a monad m with an additional 
operation malias that abstracts out the evaluation strategy and has a type m a ^ m {m a). The term 
aliasing refers to the fact that some part of effects may be performed once and their results shared in 
multiple monadic computations. The translation of the previous example using malias looks as follows: 
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chooseSize ..10 Int — t- 10 Int — t- 10 Int 
chooseSize new legacy = do 
newVal ^ new 

if newVal > then new else legacy 

resultSize : : 10 Int 
resultSize = do 

new ^ malias {lookuplnput "new_size") 

legacy ^ malias {lookuplnput "legacy_size") 

chooseSize new legacy 

The types of functions and access to function parameters are translated in the same way as in the call-by- 
name translation. The chooseSize function returns a computation 10 Int and its parameters also become 
computations of type 10 Int. When using the value of a parameter, the computation is evaluated using 
monadic bind (e.g. the line newVal ^ new in chooseSize). 

The computations passed as arguments are not the original computations as in the call-by-name 
translation. The translation inserts a call to malias for every function argument (and also for every let- 
bound value, which can be encoded using lambda abstraction and application). The computation returned 
by malias has a type m{ma), which makes it possible to perform the effects at two different call sites: 

• When simulating the call-by-value strategy, all effects are performed when binding the outer 
monadic computation before a function call. 

• When simulating the call-by-name strategy, all effects are performed when binding the inner 
monadic computation, when the value is actually needed. 

These two strategies can be implemented by two simple definitions of malias. However, by dele- 
gating the implementation of malias to the monad, we make it possible to implement more advanced 
strategies as well. We discuss some of them later in Section ID We keep the translation informal until 
Section 123] and discuss the malias operation in more detail first. 

Implementing call-by-name. To implement the call-by-name strategy, the malias operation needs to 
return the computation specified as an argument inside the monad. In the type m (m a), the outer m will 
not carry any effects and the inner m will be the same as the original computation: 

malias ::m a ^ m [m a) 
malias m = return m 

From the monad laws (see Figure[Tll, we know that applying monadic bind to a computation created from 
a value using return is equivalent to just passing the value to the rest of the computation. This means that 
the additional binding in the translation does not have any effect and the resulting program behaves as 
the call-by-name strategy. A complete proof can be found in Appendix lAl 

Implementing call-by-value. Implementing the call-by-value strategy is similarly simple. In the re- 
turned computation of type m {ma), the computation corresponding to the outer m needs to perform all 
the effects. The computation corresponding to the inner m will be a computation that simply returns the 
previously computed value without performing any effects: 

malias ::m a ^ m {m a) 

malias m = m {return o return) 
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Functor with unit and join: 
unit ::a ^ ma 
map ::ma—^ (a b) —^mb 
join m (m a) ^ m a 



Definition using bind (»=) and return: 
return ::a ^ ma 
^>3= ::m a ^ (a ^ m b) ^ m b 



Join laws {unit and map laws omitted): 



Monad laws about bind and return: 



join o mapjom = jom ojoin 
join o map unit = id =join o unit 
join o map {mapf) = mapf ojoin 



return a »=/ = f a 
m return = m 



(m >:=/) yc^g = m >:= (Ax f xy^g) 



Figure 1 : Two equivalent ways of defining monads with monad laws 



In Haskell, the second line could be written as liftM return m. The liftM operation represents the functor 
associated with the monad. This means that binding on the returned computation performs all the effects, 
obtains a value v and returns a computation return v. 

When calling a function that takes an argument of type m a, the argument passed to it using this imple- 
mentation of malias will always be constructed using the return operation. Hence the resulting behaviour 
is equivalent to the original call-by-value translation. Detailed proof can be found in Appendix [A] 

2.2 The malias operation laws 

In order to define a reasonable evaluation strategy, we require the malias operation to obey a number of 
laws. The laws follow from the theoretical background that is discussed in Section [3l namely from the 
fact that malias is the cojoin operation of a computational semi-comonad. 

The laws that relate malias to the monad are easier to write in terms of join, map and unit than using 
the formulation based on and return. For completeness, the two equivalent definitions of monads 
with the monad laws are shown in Figure [T] Although we do not show it, one can be easily defined in 
terms of the other. The required laws for malias are the following: 



The first two laws follow from the fact that malias is a cojoin operation of a comonad. The naturality law 
specifies that applying a function to a value inside a computation is the same as applying the function to a 
value inside an aliased computation. The associativity law specifies that aliasing an aliased computation 
is the same as aliasing a computation produced by an aliased computation. 

The computationality law is derived from the fact that the comonad defining malias is a computa- 
tional comonad with unit as one of the components. The law specifies that aliasing of a pure computation 
creates a pure computation. Finally, the identity law relates malias with the monadic structure, by requir- 
ing that join is a left inverse of malias. Intuitively, it specifies that aliasing a computation of type m a and 
then joining the result returns the original computation. 

All four laws hold for the two implementations of malias presented in the previous section. We prove 
that the laws hold for any monad using the standard monad laws. The proofs can be found in Appendix iBl 
We discuss the intuition behind the laws in Section 12.41 and describe their categorical foundations in 
Section [3] The next section formally presents the translation algorithm. 



map {map f) o malias 
map malias o malias 
malias o unit 
join o malias 



malias o (map f) 
malias o malias 
unit o unit 
id 



{naturality) 
{associativity) 
{computationality) 
{identity) 
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Mcbn = X 

IXx.ejcbn = unit (Xx.lejcbn) 

\e]_e2icbn = bindleijchn {^f-f leijcbn) 

llttx = eime2lcbn = i^x.lejjcbn) {eijchn 

Figure 2: Wadler's call-by-name translation of A calculus. 

Ixjcbv = unit X 

IXx.ejcbv = unit (Xx.lejcbv) 

lei ejjcbv = bind leijctv (A/, bind le2jcbv i^x.fx)) 

{Mx = e\ inealcfov = bind \e\\cbv {^x.\eT\cbv) 

Figure 3: Wadler's call-by- value translation of X calculus. 
2.3 Lambda calculus translation 

The call-by-name and call-by-value translations given in Section [TTT] were first formally introduced by 
Wadler [26 |. In this section, we present a similar formal definition of our translation based on the malias 
operation. For our source language, we use a simply-typed A calculus with let-binding: 

e E Expr e ::= ;ic | Ax.e | ^2 I Ictx = ei ine2 
T G Type T ::= a \ Ti ^ T2 

The target language of the translation is identical but for one exception - it adds a type scheme M t rep- 
resenting monadic computations. The call-by-name and call-by-value translation of the lambda calculus 
are shown in Figure[2]and Figure|3l respectively. In the translation, we write »= as bind. The translation 
of types and typing judgements are omitted for simplicity and can be found in the original paper 1*261. 

Our translation, called call-by-alias, is presented below. The translation has similar structure to 
Wadler's call-by-name translation, but it inserts malias operation in the last two cases: 



iocjcba = CC 

h\^T:2lcba = M iTijcba ^ M lT:2lcba 

Mcba = X 

{Xx.e^cba = unit (Xx-lejcba) 

le\ e2jcba = bind leijcba {Xf.bind {malias le2lcba) f) 

[letx = e\ 'm.e2icba = bind {malias lei\cba) {Xx.le2%ba) 



Ixi : Zi,..., x„ :rnhe:Tjcha= XI --M {rij.ba, ...,Xn:M {rnjcba H lej,.ba ■ M Irjcba 

The translation turns user-defined variables of type t into variables of type M r. A variable access x is 
translated to a variable access, which now represents a computation (that may have effects). A lambda 
expression is turned into a lambda expression wrapped in a pure monadic computation. 

The two interesting cases are application and let-binding. When translating function application, 
we bind on the computation representing the function. We want to call the function / with an aliased 
computation as an argument. This is achieved by passing the translated argument to malias and then 
applying bind again. The translation of let-binding is similar, but slightly simpler, because it does not 
need to use bind to obtain a function. 
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The definition of [[— Jc^a includes a well-typedness-preserving translation of typing judgements. The 
details of the proof can be found in Appendix ICl In the translation, let-binding is equivalent to {Xx.e2) e\, 
but we include it to aid the intuition and to simplify motivating examples in the next section. 

2.4 The meaning of malias laws 

Having provided the translation, we can discuss the intuition behind the malias laws and what they imply 
about the translated code. The naturality law specifies that malias is a natural transformation. Although 
we do not give a formal proof, we argue that the law follows from the parametricity of the malias type 
signature and can be obtained using the method described by Voigtlander ll25l . 

Effect conservation. The meaning of associativity and identity can be informally demonstrated by 
treating effects as units of information. Given a computation type involving a number of occurrences of 
m, we say that there are effects (or information) associated with each occurrence of m. 

The identity law specifies that join o malias does not lose effects - given a computation of type m a, 
the malias operation constructs a computation of type m{ma). This is done by splitting the effects of the 
computation between two monadic computations. Requiring that applying join to the new computation 
returns the original computation means that all the effects of the original computation are preserved, 
because join combines the effects of the two computations. 

The associativity law specifies how the effects should be split. When applying malias to an aliased 
computation of type m{ma), we can apply the operation to the inner or the outer m. Underlining second 
aliasing, the following two computations should be equal: m {m {m a)) = m {m {m a)). The law forbids 
implementations that split the effects in an asymmetric way. For instance, if m a represents a step-wise 
computation that can be executed by a certain number of steps, malias cannot execute the first half of 
steps and return a computation that evaluates the other half. The proportions associated with individual 
m values would be 1/4, 1/4 and 1/2 on the left and 1/2, 1/4 and 1/4 on the right-hand side. 

Semantics-preserving transformations. The computationality and identity (again) laws also specify 
that certain semantics-preserving transformations on the original source code correspond to equivalent 
terms in the code translated using the call-by-alias transformation. The source transformations corre- 
sponding to computationality and identity, respectively, are the following: 

let / = Ax.^i in ^2 = ^ilf ^ ^x,.e\\ 
let X = e in X = e 

The construction of the lambda function in the first equation is the only place where the translation inserts 
unit. The computationality law can be applied when a lambda abstraction appears in a position where 
malias is inserted. Thanks to the first monad law (Figure [Hi, the value assigned to / in the translation 
is unit {Xx.ei), which is equivalent to the translation of a term after the substitution. In the second 
equation, the left-hand side is translated as bind {malias e) id, which is equivalent to join {malias e), so 
the equation directly corresponds to the identity law. 

Discussion of completeness. The above discussion, together with the theoretical foundations intro- 
duced in the next section, supports the claim that our laws are necessary. We do not argue that our set of 
laws is complete - for instance, we might want to specify that aliasing of an already aUased computation 
has no effect, which is difficult to express in an equational form. 
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However, the definition of completeness, in tins context, is elusive. One possible approach that we 
plan to investigate in future work is to expand the set of semantics-preserving transformations that should 
hold, regardless of an evaluation strategy. 

3 Computational semi-bimonads 

In this section, we formally describe the structure that underlies a monad having a malias operation as 
described in the previous section. Since the malias operation corresponds to an operation of a comonad 
associated with a monad, we first review the definitions of a monad and a comonad. Monads are well- 
known structures in functional programming. Comonads are dual structures to monads that are less 
widespread, but they have also been used in functional programming and semantics (Section |5]): 

Definition 1. A monad over a category ^ is a triple {T,r\,}x) where T ■/€ is a functor, r\:hg 

is a natural transformation from the identity functor to T, and }JL is a natural transformation, 

such that the following associativity and identity conditions hold, for every object A: 

• Ma o riTA = idrA = Ma o TrjA 

Definition 2, A comonad over a category is a triple {T,e,5) where T :'tf is a functor, e:T 

is a natural transformation from T to the identity functor, and 5 :T ^ is a natural transformation 

from T to T^, such that the following associativity and identity conditions hold, for every object A: 

• T8a o8a = 5ta o Sa 

• Eta o5a = idj-A = Tea o 5a 

In functional programming terms, the natural transformation Tj corresponds to unit ::a ^ ma and 
the natural transformation ji corresponds to join ::m {m a) ma. A comonad is a dual structure to a 
monad - the natural transformation E corresponds to an operation counit ::ma ^ a and 8 corresponds 
to cojoin ::m a ^ m {m a). An equivalent formulation of comonads in functional programming uses an 
operation cobind :: m a ^ [m a ^ b) ^ m b, which is dual to »= of monads. 

A simple example of a comonad is the product comonad. The type m a stores the value of a and some 
additional state S, meaning that TA=AxS. The E (or counit) operation extracts the value A ignoring the 
additional state. The 8 (or cojoin) operation duplicates the state. In functional programming, the product 
comonad is equivalent to the reader monad TA = S ^ A. 

In this paper, we use a special variant of comonads. Computational comonads, introduced by Brookes 
and Geva f5], have an additional operation / together with laws specifying its properties: 

Definition 3. A computational comonad over a category ^ is a quadruple {T,E., 8, 7) where {T,E,8) is 
a comonad over ^ and y.hg is a natural transformation such that, for every object A, 

• Ea o 7a = idA 

• 8AoyA = JtaoJa- 

A computational comonad has an additional operation 7 which has the same type as the 77 operation 
of a monad, that is a ^ m a. In the work on computational comonads, the transformation 7 turns an 
extensional specification into an intensional specification without additional computational information. 
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In our work, we do not need the natural transformation corresponding to counit ::ma^ a. We define 
a computational ^^emZ-comonad, which is a computational comonad without the natural transformation e 
and without the associated laws. The remaining structure is preserved: 

Definition 4. A computational semi -comonad over a category 'tf is a triple {T, 5,y) where T : 'la ^ 'la is 

a functor, 5 :T is a natural transformation from T to and y.L^^T is a natural transformation 
from the identity functor to T, such that the following associativity and computationality conditions hold, 
for every object A: 

• T5ao5a = 5ta°8a 

• 5aoya = 7ta°7a- 

Finally, to define a structure that models our monadic computations with the malias operation, we 
combine the definition of a monad and computational semi-comonad. We require that the two structures 
share the functor T and that the natural transformation T] : — )■ T of a monad coincides with the natural 
transformation 7 : — )• T of a computational comonad. 

Definition 5. A computational semi-bimonad over a category is a quadruple (T, 77,/i,5) where 
(r, T],/i) is a monad over a category ^ and (r, 5,T]) is a computational semi-comonad over such 
that the following additional condition holds, for every object A: 

• o 5a = idrA 

The definition of computational semi-bimonad relates the monadic and comonadic parts of the struc- 
ture using an additional law. Given an object A, the law specifies that taking TA to T^A using the natural 
transformation 5a of a comonad and then back to TA using the natural transformation \Ia is identity. 

3.1 Revisiting the laws 

The laws of computational semi-bimonad as defined in the previous section are exactly the laws of our 
monad equipped with the malias operation. In this section, we briefly review the laws and present the 
category theoretic version of all the laws demonstrated in Section 12. 2[ We require four laws in addition 
to the standard monad laws (which are omitted in the summary below). A diagrammatic demonstration 
is shown in Figured For all objects A and B of and for all / : A — )• S in ^: 



The naturality law follows from the fact that 5 is a natural transformation and so we did not state it 
explicitly in Definition^ However, it is one of the laws that are translated to the functional programming 
interpretation. The associativity law is a law of comonad - the other law in Definition |2] does not apply 
in our scenario, because we only work with semi-comonsid that does not have natural transformation e 
(counit). The computationality law is a law of a computational comonad and finally, the identity law is 
the additional law of computational semi-bimonads. 



T^fodA 

T5a o 5a 
5a or] A 
I^a°5a 




(naturality) 
(associativity) 
(computationality ) 
(identity) 
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TA-^TB TA—^T^A A^^TA id^, 

TA ^TA 




(naturality) (associativity) (computationality) (identity) 

Figure 4: Diagramatic representation of the four additional properties of semi-bimonads 

4 Abstracting evaluation strategy in practice 

In this section, we present several practical uses of the malias operation. We start by showing how to 
write monadic code that is parameterized over the evaluation strategy and then consider expressing call- 
by-need in this framework. Then we also briefly consider parallel call-by-need and the relation between 
malias and joinads and the docase notation 1, 19,1 . 

4.1 Parameterization by evaluation strategy 

One of the motivations of this work is that the standard monadic translations for call-by-name and call- 
by -value produce code with different structure. Section 123] gave a translation that can be used with both 
of the evaluation strategies just by changing the definition of the malias operation. In this section, we 
make one more step - we show how to write code parameterized by evaluation strategy. 

We define a monad transformer lfT3l that takes a monad and turns it into a monad with malias that 
implements a specific evaluation strategy. Our example can then be implemented using functions that 
are polymorphic over the monad transformer. We continue using the previous example based on the 10 
monad, but the transformer can operate on any monad. 

As a first step, we define a type class named MonadAlias that extends Monad with the malias opera- 
tion. To keep the code simple, we do not include comments documenting the laws: 

class Monad m =^ MonadAlias m where 
malias ::m a ^ m (m a) 

Next, we define two new types that represent monadic computations using the call-by-name and call-by- 
value evaluation strategy. The two types are wrappers that make it possible to implement two different 
instances of MonadAlias for any underlying monadic computation m a: 

newtype CbV ma = CbV { runCbV -.-.ma} 
newtype CbN ma = CbN { runCbN -.-.ma} 

The snippet defines types CbV and CbN that represent two evaluation strategies. Figure |5] shows the 
implementation of three type classes for these two types. The implementation of the Monad type class is 
the same for both types, because it simply uses return and operations of the underlying monad. The 
implementation of MonadTrans wraps a monadic computation m a into a type CbV m a and CbN m a, 
respectively. Finally, the instances of the MonadAlias type class associate the two implementations of 
malias (from Section |2?T]) with the two data types. 
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instance Monad m =^ Monad {CbV m) where 

return v = CbV [return v) 

{CbV a) >:^f = CbV [a >:= {runCbV of)) 
instance Monad m =^ Monad [CbN m) where 

return v = CbN (return v) 

(CbN a) >:=/ = CbN {a >:= {runCbN of)) 

instance MonadTrans CbV where lift = CbV 
instance MonadTrans CbN where lift = CbN 

instance Monad m =^ MonadAlias {CbV m) where 

malias m = m ^>3= {return o return) 
instance Monad m ^ MonadAlias {CbN m) where 

malias m = return m 

Figure 5: Instances of Monad, MonadTrans and MonadAlias for evaluation strategies 

Example. Using the previous definitions, we can now rewrite the example from Section 11.11 using 
generic functions that can be executed using both runCbV and runCbN. Instead of implementing malias 
for a specific monad such as 10 a, we use a monad transformer t that lifts the monadic computation to 
either CbV 10 a or to CbN 10 a. This means that all functions will have constraints MonadTrans t, spec- 
ifying that ? is a monad transformer, and MonadAlias {t m), specifying that the computation implements 
the malias operation. 

In Haskell, this can be succinctly written using constraint kinds fSV that make it possible to define a 
single constraint EvalStrategy t m that combines both of the condition^ 

type EvalStrategy tm = {MonadTrans t, MonadAlias {t m)) 

Despite the use of the type keyword, the identifier EvalStrategy actually has a kind Constraint, which 
means that it can be used to specify assumptions about types in a function signature. In our example, the 
constraint EvalStrategy 1 10 denotes monadic computations based on the 10 monad that also provide an 
implementation of MonadAlias: 

chooseSize : : EvalStrategy 1 10 ^ 1 10 Int ^ 1 10 Int 1 10 Int 
chooseSize new legacy = do 
newVal ^ new 

if newVal > then new else legacy 

resultSize : : EvalStrategy 1 10 ^ 1 10 Int 
resultSize = do 

new ^ malias$lift {lookuplnput "new_size") 

legacy ^ malias $ lift {lookuplnput "legacy_size") 

chooseSize new legacy 

Compared to the previous version of the example, the only significant change is in the type signature of 
the two functions. Instead of passing computations of type 10 a, they now work with computations t lOa 

^Constraint kinds are available in GHC 7.4 and generalize constraint families proposed by Orchard and Schrijvers 1181 



Tomas Petricek 



79 



with the constraint EvalStrategy 1 10. The result of lookuplnput is still 10 Int and so it needs to be lifted 
into a monadic computation 1 10 Int using the lift function. 

The return type of the resultSize computation is parameterized over the evaluation strategy t. This 
means that we can call it in two different ways. Writing runCbN resultSize executes the function using 
call-by-name and writing runCbV resultSize executes it using call-by-value. However, it is also possible 
to implement a monad transformer for call-by-need. 

4.2 Implementing call-by-need strategy 

In his paper introducing the call-by-name and call-by-value translations for monads, Wadler noted: "It 
remains an open question whether there is a translation scheme that corresponds to call-by-need as op- 
posed to call-by-name" 1261 . We do not fully answer this question, however we hope to contribute to the 
answer. In particular, we show how to use the mechanism described so far to turn certain monads into an 
extended versions of such monads that provide the call-by-need behaviour. 

In the absence of effects, the call-by-need strategy is equivalent to the call-by-name strategy, with the 
only difference in that performance characteristics. In the call-by-need (or lazy) strategy, a computation 
passed as an argument is evaluated at most once and the result is cached afterwards. 

The caching of results needs to be done in the malias operation. This cannot be done for any monad, 
but we can define a monad transformer similar to the ones presented in the previous section. In particular, 
we use Svenningsson's package |[22l . which defines a transformer version of the ST monad ifTTl . As 
documented in the package description, the transformer should be applied only to monads that yield a 
single result. Combining lazy evaluation with non-determinism is a more complex topic that has been 
explored by Fischer et al. |6|. 

newtype CbL s ma = CbL { unCbL : : 57T s ma} 

Unlike CbV and CbN, the CbL type is not a simple wrapper that contains a computation of type m a. 
Instead, it contains a computation augmented with some additional state. The state is used for caching the 
values of evaluated computations. The type STT s ma represents a computation m a with an additional 
local state "tagged" with a type variable s. The use of a local state instead of e.g. 10 means that the 
monadic computation can be safely evaluated even as part of purely functional code. The tags are used 
merely to guarantee that state associated with one STT computation does not leak to other parts of the 
program. 

Implementing the Monad and MonadTrans instances follows exactly the same pattern as instances of 
other transformers given in Figure [51 The interesting work is done in the malias function of MonadAlias: 

instance Monad m =^ MonadAlias {CbL s m) where 
malias (CbL marg) = CbL$ do 
r newSTRef Nothing 
return {CbL$ do 
rv ^ readSTRef r 
case rv of 

Nothing — )• marg »= A v writeSTRef r {Just v) » return v 
Just V —7- return v) 

The malias operation takes a computation of type m a and returns a computation m {ma). The monad 
transformer wraps the underlying monad inside STT, so the type of the computation returned by malias 
is equivalent to a type STT s m {STT s ma). 
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The fact that both outer and inner STT share the same tag s means that they operate on a shared state. 
The outer computation allocates a new reference and the inner computation can use it to access and 
store the result computed previously. The allocation is done using the newSTRef function, which creates 
a reference initialized to Nothing. In the returned (inner) computation, we first read the state using 
readSTRef. If the value was computed previously, then it is simply returned. If not, the computation 
evaluates marg, stores the result in a reference cell and then returns the obtained value. 

Discussion. After implementing runCbL function (which can be done easily using runST), the example 
in Section l4~T] can be executed using the CbL type. With the call-by-need semantics, the program finally 
behaves as desired: if the value of the "new_size" key is greater than zero, then it reads it only once, 
without reading the value of the "legacy_size" key. The value of "legacy_size" key is accessed 
only if the value of the "new_size" key is less than zero. 

Showing that the above definition corresponds to call-by-need formally is beyond the scope of this 
paper. However, the use of STT transformer adds a shared state that keeps the evaluated values, which 
closely corresponds to Launchbury's environment-based semantics of lazy evaluation [9 |. 

We do not formally prove that the malias laws hold for the above implementation, but we give an 
informal argument. The naturality law follows from parametricity. Computations considered in the 
associativity law are of type m (m {ma)); both sides of the equation create a computation where the 
two outer m computations allocate a new reference (where the outer points to the inner) and the single 
innermost m actually triggers the computation. The computationality law holds, because aliasing of a unit 
computation cannot introduce any effects. Finally, the left-hand side of identity creates a computation 
that allocates a new reference that is encapsulated in the returned computation and cannot be accessed 
from elsewhere, so no sharing is added when compared with the right-hand side. 

4.3 Parallel call-by-need strategy 

In this section, we consider yet another evaluation strategy that can be implemented using our scheme. 
The parallel call-by-need strategy [2J is similar to call-by-need, but it may optimistically start evaluating 
a computation sooner, in parallel with the main program. When carefully tuned, the evaluation strategy 
may result in a better performance on multi-core CPUs. 

We present a simple implementation of the malias operation based on the monad for deterministic 
parallelism by Marlow et al. [14J. By translating purely functional code to a monadic version using our 
translation and the Par monad, we get a program that attempts to evaluate arguments of every function 
call in parallel. In practice, this may introduce too much overhead, but it demonstrate that parallel 
call-by-need strategy also fits with our general framework. 

Unlike the previous two sections, we do not define a monad transformer that can embody any 
monadic computation. For example, performing 10 operations in parallel might introduce non-determinism. 
Instead, we implement malias operation directly for computations of type Par a: 

instance MonadAlias Par where 

malias m = spawn m >£3= return o get 

The implementation is surprisingly simple. The function spawn creates a computation Par {IVar a) that 
starts the work in background and returns a mutable variable (I-structure) that will contain the result 
when the computation completes. The inner computation that is returned by malias calls a function 
get -.-.IVar a — )■ Par a that waits until IVar has been assigned a value and then returns it. 
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Using the above implementation of malias, we can now translate purely functional code to a monadic 
version that uses parallel call-by-need instead of the previous standard evaluation strategies (that do not 
introduce any parallelism). For example, consider a naive Fibonacci function: 

fibSeq n\n ^ \ = n 

fibSeq n =fibSeq {n — \) +fibSeq {n — 2) 

The second case calls the + operator with two computations as arguments. The translated version passes 
these computations to malias, which starts executing them in parallel. The monadic version of the + 
operator then waits until both computations complete. If we translate only the second case and manually 
add a case that calls sequential version of the function for inputs smaller than 30, we get the following: 

fibPar n\n<30 = return (fibSeq n) 
fibPar n = do 

nl malias % fibPar (« — 1 ) 

n2 •(— malias % fibPar [n — 2) 

liftMl (+) nl nl 

Aside from the first line, the code directly follows the general translation mechanism described earlier. 
Arguments of a function are turned to monadic computations and passed to malias. The inner computa- 
tions obtained using monadic bind are then passed to a translated function. 

Thanks to the manual optimization that cdS}&fibSeq for smaller inputs, the function runs nearly twice 
as fast on a dual-core machin^. Parallel programming is one of the first areas where we found the malias 
operation useful. We first considered it as part of joinads, which are discussed in the next section. 

Discussion. Showing that the above implementation actually implements parallel call-by-need could 
be done by relating our implementation of malias to the multi-thread transitions of [2]. Informally, each 
computation that may be shared is added to the work queue (using spawn) when it occurs on the right- 
hand side of a let binding, or as an argument in function application. The queued work evaluates in 
parallel with the main program and the get function implements sharing, so the semantics is lazy. 

As previously, the naturality law holds thanks to parametricity. To consider other laws, we need 
a formal model that captures the time needed to evaluate computations. We assume that evaluating a 
computation created by unit takes no time, but all other computations take non-zero time. Moreover, all 
spawned computations start executing immediately (i.e. the number of equally fast threads is unlimited). 

In the associativity law, the left-hand side returns a computation that spawns the actual work and 
then spawns a computation that waits for its completion. The right-hand side returns a computation 
that schedules a computation, which then schedules the actual work. In both cases, the actual work 
is started immediately when the outer m computation is evaluated, and so they are equivalent. The 
computationality law holds, because a unit computation evaluates in no time. Finally, the left-hand 
side of identity returns a computation that spawns the work and then waits for its completion, which is 
semantically equivalent to just running the computation. 

4.4 Simplifying Joinads 

Joinads 1201 [T9i were designed to simplify programming with certain kinds of monadic computations. 
Many monads, especially from the area of concurrent or parallel programming provide additional oper- 

^When called with input 37 on a Core 2 Duo CPU, the sequential version runs in 8.9s and the parallel version in 5.1s. 
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ations for composing monadic computations. Joinads identify three most common extensions: parallel 
composition, (non-deterministic) choice and aliasing. 

Joinads are abstract computations that form a monad and provide the tliree additional operations 
mentioned above. The work on joinads also introduces a syntactic extension for Haskell and F# that 
makes it easier to work with these classes of computations. For example, the following snippet uses the 
Par monad to implement a function that tests whether a predicate holds for all leafs of a tree in parallel: 

all ::{a—> Bool) Tree a — > Par Bool 

all p {Leaf v) = return (p v) 

all p {Node left right) = 

docase {all p left, all p right) of 

{False, ?) — >• return False 

{1, False) — >■ return False 

{allL,allR) — >■ return {allL A allR) 

The docase notation intentionally resembles pattern matching and has similar semantics as well. The 
first two cases use the special pattern ? to denote that the value of one of the computations does not 
have to be available in order to continue. When one of the sub-branches returns False, we know that the 
overall result is False and so we return immediately. Finally, the last clause matches if neither of the two 
previous are matched. It can only match after both sub-trees are processed. 

Similarly to do notation, the docase syntax is desugared into uses of the joinad operations. The 
choice between clauses is translated using the choice operator. If a clause requires the result of multiple 
computations (such as the last one), the computations are combined using parallel composition. 

If a computation, passed as an argument, is accessed from multiple clauses, then it should be evalu- 
ated only once and the clauses should only access aliased computation. This motivation is similar to the 
one described in this article. Indeed, joinads use a variant of the malias operation and insert it automati- 
cally for all arguments of docase. This is very similar to how the translation presented in this paper uses 
malias. If aliasing was not done automatically behind the scenes, we would have to write: 

all p {Leaf v) = return (p v) 

all p {Node left right) = do 
/ ^ malias {all p left) 
r ^ malias {all p right) 
docase r) of 

{False, ?) — > return False 
{1, False) return False 
{allL, allR) return {allL A allR) 

One of the limitations of the original design of joinads is that there is no one-to-one correspondence 
between the docase notation and what can be expressed directly using the joinad operations. This is 
partly due to the automatic aliasing of arguments, which inserts malias only at very specific locations. We 
believe that integrating a call-by-alias translation, described in this article, in a programming language 
could resolve this situation. It would also separate the two concerns - composition of computations using 
choice and parallel composition (done by joinads) and automatic aliasing of computations that allows 
sharing of results as in call-by-need or parallel call-by-need. 
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5 Related work 

Most of the work that directly influenced this work has been discussed throughout the paper. Most 
importantly, the question of translating pure code to a monadic version with call-by-need semantics was 
posed by Wadler 11261 . To our knowledge, this question has not been answered before, but there is various 
work that either uses similar structures or considers evaluation strategies from different perspectives. 

Monads with aliasing. Numerous monads have independently introduced an operation of type ma ^ 
m {m a). The eagerly combinator of the Ore monad lITOl causes computation to run in parallel, effec- 
tively implementing the parallel call-by-need evaluation strategy. The only law that relates eagerly to 
operations of a monad is too restrictive to allow the call-by-value semantics. 

A monad for purely functional lazy non-deterministic programming [6] uses a similar combinator 
share to make monadic (non-deterministic) computations lazy. However, the call-by-value strategy is 
inefficient and the call-by-name strategy is incorrect, because choosing a different value each time a 
non-deterministic computation is accessed means that generate and test pattern does not work. 

The share operation is described together with the laws that should hold. The HNF law is similar 
to our computationality . However, the Ignore law specifies that the share operation should not be strict 
(ruling out our call-by-value implementation of malias). A related paper ||4l discusses where share needs 
to be inserted when translating lazy non-deterministic programs to a monadic form. The results may be 
directly applicable to make our translation more efficient by inserting malias only when required. 

Abstract computations and comonads. In this paper, we extended monads with one component of 
a comonadic structure. Although less widespread than monads, comonads are also useful for capturing 
abstract computations in functional programming. They have been used for dataflow programming [23], 
array programming [17], environment passing, and more [8|. In general, comonads can be used to 
describe context-dependent computations [24], where cojoin (natural transformation 5) duplicates the 
context. In our work, the corresponding operation malias splits the context (effects) in a particular way 
between two computations. 

We only considered basic monadic computations, but it would be interesting to see how malias 
interacts with other abstract notions of computations, such as applicative functors |[T5l . arrows Q or 
additive monads (the MonadPlus type-class). The monad for lazy non-deterministic programming |[6l . 
mentioned earlier, implements MonadPlus and may thus provide interesting insights. 

Evaluation strategies. One of the key results of this paper is a monadic translation from purely func- 
tional code to a monadic version that has the call-by-need semantics. We achieve that using the monad 
transformer ifTSll for adding state. 

In the absence of effects, call-by-need is equivalent to call-by-name, but it has been described for- 
mally as a version of A -calculus by Ariola and Felleisen [1]. This allows equational reasoning about 
computations and it could be used to show that our encoding directly corresponds to call-by-need, sim- 
ilarly to proofs for other strategies in Appendix [A] The semantics has been also described using an 
environment that models caching ||9l|2Tl, which closely corresponds to our actual implementation. 

Considering the two basic evaluation strategies, Wadler |27| shows that call-by-name is dual to call- 
by-value. We find this curious as the two definitions of malias in our work are, in some sense, also dual 
or symmetric as they associate all effects with the inner or the outer monad of the type m {ma). Fur- 
thermore, the duality between call-by-name and call-by-value can be viewed from a logical perspective 
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thanks to the Curry-Howard correspondence. We beUeve that finding a similar logical perspective for our 
generalized strategy may be an interesting future work. 

Finally, the work presented in this work unifies monadic call-by-name and call-by-value. In a non- 
monadic setting, a similar goal is achieved by the call-by -push-value calculus |fT2|. The calculus is more 
fine-grained and strictly separates values and computations. Using these mechanisms, it is possible to 
encode both call-by-name and call-by-value. It may be interesting to consider whether our computations 
parameterized over evaluation strategy (Section |4T1) could be encoded in call-by-push-value. 

6 Conclusions 

We presented an alternative translation from purely functional code to monadic form. Previously, this 
required choosing either the call-by-need or the call-by-value translation and the translated code had 
different structure and different types in both cases. Our translation abstracts the evaluation strategy into 
a function malias that can be implemented separately providing the required evaluation strategy. 

Our translation is not Umited to the above two evaluation strategies. Most interestingly, we show 
that certain monads can be automatically turned into an extended version that supports the call-by-need 
strategy. This answers part of an interesting open problem posed by Wadler [26]. The approach has 
other interesting applications - it makes it possible to write code that is parameterized by the evaluation 
strategy and it allows implementing a parallel call-by-need strategy for certain monads. 

Finally, we presented the theoretical foundations of our approach using a model described in terms of 
category theory. We extended the monad structure with an additional operation based on computational 
comonads, which were previously used to give intensional semantics of computations. In our setting, 
the operation specifies the evaluation order The categorical model specifies laws about malias and we 
proved that the laws hold for call-by-value and call-by-name strategies. 
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= bind leijcba {Xf.bind {unit le2\cba) /)) (definition) 
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Figure 6: Proving that using an appropriate malias is equivalent to call-by-name. 



A Equivalence proofs 

In this section, we show that our translation presented in Section l23] can be used to implement standard 
call-by-name and call-by-value. We prove that using an appropriate definition of malias from Section lTT] 
gives the same semantics as the standard translations described by Wadler [26]. 



Call-by-name. The translation of types is the same for our translation and the call-by-name translation. 
In addition, the rules for translating variable access and lambda functions are also the same. This means 
that we only need to prove that our translation of let-binding and function application are equivalent. 
When implementing call-by-name using our translation, we use the following definition of malias: 

malias m = unit m 



Using this definition and the left identity monad law, we can now show that our call-by-alias translation 
is equivalent to the translation from Figure |2] The Figure [6] shows the equations for function application 
and let-binding. 



Call-by-value. Proving that appropriate definition of malias gives a term that corresponds to the one 
obtained using standard call-by-value translation is more difficult. In the call-by-value translation, func- 
tions are translated to a type Ti — )• M T2, while our translation produces functions of type M Xi — > M T2. 
As a reminder, the definition of malias that gives the call-by-value behaviour is the following: 

malias m = bind m {unit o unit) 

To prove that the two translations are equivalent, we show that the following invariant holds: when using 
the above definition of malias and our call-by-alias translation, a monadic computation of type M T that 
is assigned to a variable x always has a structure unit Xy where x,, is a variable of type T. 

The sketch of the proof is shown in Figure |7j We write e\ = e2 to mean that the expression ei in 
the call-by-alias translation corresponds to an expression e2 in call-by-value translation. This means that 
expressions of form unit Xy translate to values x, variable declarations of Xy (in lambda abstraction and 
let-binding) translate to declarations of x and all function values of type M Ti — )• M T2 become Ti — > M T2. 
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= bind {bind {eijcba {unit o unit)) {Xx.le2}cba) (definition) 

= bind [e\\cba {Xxy .bind {unit {unit Xy)) (Ax.JeiJcfoa)) (associativity) 

= bind leijcba{^Xy.{Xx.le2}cba) {unit Xy)) (left identity) 

= bind {eijcbv {^x.le2jcbv) (correspondence) 

= |let;c = ei ine2lcfov (translation) 



Figure 7: Proving that using an appropriate malias is equivalent to call-by-value. 



B Proofs for two implementations 



In this section, we prove that the two implementations of malias presented in Section [2?T] obev the malias 
laws. We use the formulation of monads based on a functor with additional operations join and unit. The 
proof reUes on the following laws that hold about join and unit: 



map {g of) = {map g) o {map f) (functor) 

unit of = map f o unit (natural unit) 

join o map {map f) = map f ojoin (natural join) 

join o map join = join ojoin (assocjoin) 

join o unit = join o map unit = id (identity) 



The first law follows from the fact that map corresponds to a functor The next two laws hold because 
unit and join are both natural transformations. Finally, the last two laws are additional laws that are 
required to hold about monads (a precise definition can be found in Section [3]). 

The proofs that the two definitions of malias (implementing call-by-name and call-by-value strate- 
gies) are correct can be found in Figure [8] and Figure |9l respectively. The proofs use the above monad 
laws. We use a definition malias = map unit, which is equivalent to the definition in Appendix lAl The fig- 
ures include proofs for the four additional malias laws as defined in Section [Z2l naturality, associativity, 
computationality and identity. 



Evaluation strategies for monadic computations 



map (map f) o malias 

= map (map f) o unit (definition) 

= unit o map f (naturality) 

= malias o map f (definition) 



map malias o malias 
= map unit o unit 
= unit o unit 
= malias o malias 



(definition) 
(natural unit) 
(definition) 



malias o unit 
= unit o unit 



(definition) 



join o malias 
= join o unit 
= id 



(definition) 
(identity) 



Figure 8: Call-by-name definition of malias obeys the laws 



map {map f) o malias 

= map {map f) o map unit (definition) 

= map {map f o unit) (functor) 

= map {unit o /) (natural unit) 

= map unit o map f (functor) 

= malias o map f (definition) 

map malias o malias 

= map {map unit) o {map unit) (definition) 

= map {map unit o unit) (functor) 

= map [unit o unit) (natural unit) 

= map unit o map unit (functor) 

= malias o malias (definition) 



malias o unit 

= map unit o unit 
= unit o unit 



(definition) 
(natural unit) 



join o malias 

= join o map unit 
= id 



(definition) 
(identity) 



Figure 9: Call-by- value definition of malias obeys the laws 
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C Typing preservation proof 

In this section, we show that our translation preserves typing. Given a well-typed term e of type z, the 
translated term lejcba is also well-typed and has a type |[T|c;,a. In the rest of this section, we write |— ] 

for [— ]c/)a- To show that the property holds, we use induction over the typing rules, using the fact that 
|t] = M t' for some t'. The inductive construction of the typing derivation follows the following rules: 



|r,x: Thx: t] 



[r],x:MlTlhx:M|T] 



ir,^ : Ti h e : T2I 



ri,^:MlTilhH:M|T2l 



|r h lx.e : Ti ^ T2I 



[r] h unit (Ax.H) : M (M [ti] ^ M {^2}) 



[rhei:Ti^T2] [rhe2:Til 



m h : M (M |Til ^ M IT2I) r h ie2j : M |ti1 



[rhei 62 :T2l 



r h Zj/wJ [eij {Xf.bind {malias {ei}) /)) : M IT2I 



ri h [eil : M [Til ■■ M [Til ^ lei} : M IT2I 



[r h let X = ei in ^2 : '^2} 



[rl h (ma//a5 feij) (Xx-leij) : M [T2I 



